"UVA-Migut-MC1"
VAST 2012 Challenge
Mini-Challenge 1: Bank of Money Enterprise: Cyber Situation Awareness
Team Members:
Diederik Bakker, University of Amsterdam,
Diederik.Bakker@student.uva.nl
Justin van Wees, University of Amsterdam,
justin@vwees.net
Bart de Goede, University of Amsterdam,
Bart.deGoede@student.uva.nl
Nick Oude Lenferink, University of Amsterdam,
nok600@few.vu.nl
Haska Steltenphol, University of Amsterdam,
Tonka.Steltenpohl@student.uva.nl
Gosia Migut, University of Amsterdam,
mmigut@gmail.com PRIMARY
Marcel Worring, University of Amsterdam,
m.worring@uva.nl
Student Team:
YES
Tool(s):
In the analysis of the data from the Bank of Money we have used the following tools:
The student team of University of Amsterdam developed own software during
the Visual Analytics course taught
Spring 2012 by dr. M. Worring and M. Migut. The client side is developed in D3. The server side uses the Flask microframwork to preform aggregations on the data and to handle client requests. All data is stored in a Postgres database with multiple indexes to improve performance. Redis is used as a caching layer in which query and aggregation results are stored. Data between client and server is exchanged in JSON.
Video:
This is the link to our video:
Amsterdam-MC1-video.wmv
Answers to Mini-Challenge 1 Questions:
MC
1.1 Create a visualization of the health and policy status of the entire Bank of Money enterprise as of 2 pm BMT (BankWorld Mean Time) on February 2. What areas of concern do you
observe?
We have identified the following areas of concern:
-
At 2p.m. there is only one region where policy status 5 occurs.
That suggest that this reagion might be a source of the virus, see figure 1. However, it should be investigated whether there where deviations in policy status early and later.
Figure 1: At 2.00 p.m. only the one region of the entire Bank of Money is infected with possible virus (policy status 5).
-
From the visualization of the policy status (policy status 1 to 4) for all the region, see figure 2, we can clearly see that regions 5 and 10 do not report policy statuts 1 at any time.
The headquartes, regions 1 to 12, regions 24, 43, and 48 all report policy status 4, meaning that serious policy deviations occurs in those regions.
Figure 2: Policy status (1-4) of the entire Bank of Money for each region.
-
From the visualization of the activity flag for all the region, see figure 3, we can not conclude any abnormal behaviour.
Most of the regions show similar activity pattern. The regions 11, 34, and 48 pop up as they only report activty flag 1, meaning they are never under maintenance.
The regions: 1, 2, 32, 33, 35, 36, 37, 38, 41, 47, 49, 50 only report activity flag 1 and 2. This is not consistent with the pattern of the majority of the regions.
In regions 2 and 3 relatively more machines are under maintenance.
However, none of these observations is conclusive and they require further investigation.
Figure 3: Activity flag of the entire Bank of Money for each region.
MC
1.2 Use your visualization tools to look at how the network’s status changes over time. Highlight up to five potential anomalies in the network and provide a visualization of each. When did each anomaly begin
and end? What might be an explanation of each anomaly?
We have found four potential anomalies.
-
Firstly, we have located a virus infection originating from datacenter 2.
We explored whether a policy status 5 shows up on a map by exploring each 15-minutes time step on the time line.
The first case of policy status 5 took place at 11.45 a.m. BMT on the 2nd of February.
By zooming into this location we see that amount of infected machines in this region increases over time, see figure 2.
Our analysis showed that the patient zero machine was 172.2.194.20, a server with a compute function. We have found this anomaly through visualizing policy status 5 on the geo map interactively connected with the time slider as seen in figure 1. Before the machine went to policy status 5 it had policy status 2 at 08.15, and 3 at 09.15, 4 at 09.30 as seen in figure 3. The virus infection spreads throughout all of Bankworld as seen on figure 4 and the network does not recover.
Figure 1: First infection.
Figure 3: Policy status 5 for the infected region.
Figure 2: Policy status for the first infected machine IP: 172.2.194.20
Figure 4: The map of the world with al infected locations.
-
Secondly, we noticed that machines in region 10 and 5 never report policy status 1. We discovered this by exploring the geomap. We selected policy status 1 as node colour variable. Therefore, we can see the relative amount of machines reporting policy stauts 1 for each time-step as explored through the timeline. This functionality makes regions 10 and 5 pop out as seen in figure 5. A further analysis of the policy status 1 over time for region 5 and 10 supported our notion, as it shows that no policy status 1 is reported. Figure 6 shows the empty graph for policy status 1 for region 10 indicating that no policy 1 was reported in this region.
Figure 5: Policy status 1 as node colour variable.
Figure 6: Policy status 1 for region 10 over time shows an empty graph.
-
Thirdly, we noticed a large amount of machines stopped reporting in region 25.
To explore the normal activity of the machines thrhough time we looked at the number of machines reporting their status. Most regions show similar patterns.
By displaying activity flag 1 as the node colour we noticed an anomaly on the geomap, as seen in figure 7.
When graphing the policystatus reports over time, see figure 8, we clearly see a gap in machine activity fro region 25 starting at 11.15 on the 2nd of February. The gap starts forming slowly and takes a sharp descend at 12.15p.m. Around 04.30 a.m. on the 3rd of February the anomaly is gone and regular pattern found in other regions reoccurs in region 25. An interesting finding is that the downtime does not seem related to maintenance, as seen in figure 9. The downtime only occurs in certain branches of the region with no discernible pattern. Possible explanations could be a electrify blackout, strike, or natural disaster.
Figure 7: Geomap with activity flag 1.
Figure 8: Policy status for region 25 over time.
Figure 9: Maintaenance status for region 25 over time.
-
A fourth anomaly we encountered consisted of a significant increase of machines reporting in the headquarters region, as seen in figure 10. This increase occurs at 6.15p.m. at the 2nd of February as seen by activity flags graphed in figure 10. The number of connections also increases. It must be noted that the headquarters region is an aggregation of the headquarters and various datacenters. It is hard to explain the sudden increase in machine numbers as we do not know the regular pattern of this region and thus cannot discern whether the added machines should be on or off normally.
Figure 10: Policy status for region headquarters.